home *** CD-ROM | disk | FTP | other *** search
- '\" Copyright 1991 Regents of the University of California
- '\" Permission to use, copy, modify, and distribute this
- '\" documentation for any purpose and without fee is hereby
- '\" granted, provided that this notice appears in all copies.
- '\" The University of California makes no representations about
- '\" the suitability of this material for any purpose. It is
- '\" provided "as is" without express or implied warranty.
- '\"
- '\" $Header: /sprite/lib/forms/RCS/cmd.man,v 1.3 91/01/07 17:52:58 mottsmth Exp $ SPRITE (Berkeley)
- '/"
- .so \*(]ltmac.sprite
- .HS SCVS cmds
- .BS
- '\" Note: do not modify the .SH NAME line immediately below!
- .SH NAME
- scvs \- Sprite Concurrent Version System
- .SH SYNOPSIS
- \fBscvs\fP [\fIscvs_options\fP] [\fIcvs_options\fP] \fIcommand [command_options] [command_args]\fP
- .SH OPTIONS
- .IP "\fB\-V\fP" 15
- Print out verbose status messages during processing.
- .IP "\fB\-D\fP" 15
- Print out debugging information.
- .IP "\fB\-help\fP" 15
- Print a summary of the command-line options and exit without updating
- any targets.
- .BE
-
- .SH DESCRIPTION
- .PP
- \fBScvs\fP is a front end to the \fBcvs\fP source control system, which
- in turn is turn a front end for \fBrcs\fP.
- It would probably help to be familiar with both
- \fBcvs\fP and \fBrcs\fP before dealing with \fBscvs\fP.
- \fBScvs\fP has the following
- features in addition to those of \fBcvs\fP and \fBrcs\fP:
- .TP
- \(bu
- A configuration file is used to specify the root of the \fBcvs\fP repository,
- rather than an environment variable or a command line option.
- .TP
- \(bu
- \fBScvs\fP keeps track of who has copies of which modules. When you check out
- a module \fBscvs\fP will tell you about other copies of the same
- module you might have, and about other users that have copies of the module.
- This allows users to coordinate their modifications to a module.
- '\" .TP
- '\" \(bu
- '\" If the most recent version of a module is checked out then the corresponding
- '\" object files are retrieved from the appropriate directory specified in the
- '\" configuration file.
- .TP
- \(bu
- Changes to several modules can be committed simultaneously.
- .TP
- \(bu
- \fBScvs\fP remembers the options used to checkout a module, so that subsequent
- updates of the module use the same options, thus guaranteeing that the
- same version of the module is updated.
- .TP
- \(bu
- \fBScvs\fP has limited support for symbolic links.
- When a module is checked into the repository any symbolic links it
- contains are stored in a file called \fISCVS/links\fP.
- When a module is checked out its symbolic links are created from the
- contents of \fISCVS/links\fP.
- .SH COMMANDS
- .PP
- Each invocation of \fBscvs\fP must specify a particular command to be performed.
- Most of these commands are slight variations on the corresponding \fBcvs\fP
- commands.
- .TP
- \fBadd\fP [\fB\-m\fP '\fImessage\fP'] \fIfiles...\fP
- Create a new file or directory in the repository. Files are not actually
- added to the repository until a \fBcommit\fP command is issued. See the
- \fBcvs\fP man page for more details.
- .TP
- \fBcheckout\fP [\fB\-QqlnfPi\fP] [\fB\-c\fP] [\fB\-r\fP \fItag\fP | \fB\-D\fP \fIdate\fP] \fImodules\fP...
- Retrieves copies of the specified modules from the repository.
- For each module a
- subdirectory with the module's name
- is made in the current directory and the module's source tree is put in
- the subdirectory.
- '\" If the most recent version of the module is checked out then the corresponding
- '\" object files are also copied into the source tree, assuming that the
- '\" object file directory is specified in the config file (see
- '\" \fISCVS.config\fP in the
- '\" \fBFILES\fP section below).
- The default is to check out the most recent version of the module, although
- a particular version can be checked out by using
- either the \fB\-r\fP
- or \fB\-D\fP options, which will check out a version matching the
- given tag or date, respectively.
- The semantics of the \fBscvs\fP checkout command differ from \fBcvs\fP's
- in that empty directories are
- pruned unless the \fB\-P\fP option is given.
- Empty directories usually occur if you check out a version of a module
- from before a directory was created.
- The \fB\-Q\fP and \fB\-q\fP options cause varying degrees of quietness, and the
- \fB\-l\fP option causes the command to not be recursive.
- .SP
- The \fBcheckout\fP command will tell you of other copies of the module that
- you might have, and about other users that have copies of the module.
- If you are checking out a version to go off on your own and make changes
- that will never be checked back in, then you should use the \fI\-i\fP
- option. You will not be listed as having an official copy of the module,
- so other people will not be told that you have a copy. Everything else
- works the same, however.
- .SP
- \fBco\fP can be used as an abbreviation for \fBcheckout\fP.
- .TP
- \fBcommit\fP [\fB\-fnl\fP] [\fB\-m\fP '\fIlog_message\fP'] [\fB\-r\fP \fIrevision\fP] [\fImodules...\fP] [\fIfiles...\fP]
- The \fBcommit\fP
- command is used to check in the changes made to your copies of modules.
- If no modules are specified then the current directory is checked in.
- \fBScvs\fP differs from \fBcvs\fP
- in that multiple modules can be checked in simultaneously,
- and that commit is recursive.
- \fBScvs\fP
- achieves this by locking all modules, verifying that they are up-to-date
- with the sources in the repository, then committing the changes.
- \fBScvs\fP will also update a snapshot or installed copy of the sources
- as indicated in the \fISCVS.config\fP file (see \fBFILES\fP section below).
- .SP
- The \fB\-f\fP option allows you to commit files that do not contain the
- RCS $Id or $Header keywords. The \fB\-r\fP sets the RCS version number,
- and the \fB\-n\fP option causes any commit command in the module database
- to not be run. If the \fB\-m\fP option is not specified than an editor
- will be invoked to allow you to enter the log message.
- .SP
- \fBci\fP can be used as an abbreviation for \fBcommit\fP.
- .TP
- \fBdiff\fP [\fB\-lR\fP] [\fIrcsdiff_options\fP] [\fIfiles...\fP]
- Same as for \fBcvs\fP. Runs \fBrcsdiff\fP on the specified files, or on
- only those files that you have changed.
- \fBDiff\fP is recursive unless the \fB\-l\fP option is specified.
- If no options are given \fBdiff\fP will print out the differences between
- your copy of the file and the copy you checked out, i.e. it prints
- the changes you made to the file.
- If the \fB\-R\fP option is given then the differences between your
- copy of the file and the current version is given.
- This is useful if your copy is out-of-date and you want to see what
- changed.
- See the \fBrcsdiff\fP man page for more details on the options.
- .TP
- \fBdone\fP [\fB\-d\fP] \fImodules...\fP
- When you have finished with a module you should use the \fBdone\fP
- command, so that \fBscvs\fP
- can update its database of module copies.
- If the \fB\-d\fP
- option is given then your copy of the module will be deleted.
- If your copy differs from the repository \fBscvs\fP
- will ask you whether
- or not you are really done.
- Make sure you really, truly are done before running this command,
- particularly with the \fB\-d\fP option.
- .TP
- \fBinfo\fP [\fB\-l\fP] [\fIfiles...\fP]
- Prints out status information about your sources.
- Output is the same as for the \fBupdate\fP command.
- \fBInfo\fP is recursive unless the \fB\-l\fP option is given.
- .TP
- \fBjoin\fP [\fB\-Qqf\fP] [\fB\-r\fP \fItag\fP | \fB\-D\fP \fIdate\fP] \fIfiles...\fP
- Same as for \fBcvs\fP. Used to merge in a new vendor release of a software
- package.
- See the \fBcvs\fP man page for details.
- .TP
- \fBlock\fP [\fB\-rw\fP] [\fImodules...\fP]
- Each
- \fBscvs\fP command
- locks the module in the repository before mucking
- around with it, thus preventing concurrent \fBscvs\fP commands from creating
- chaos.
- If you wish to run several \fBscvs\fP commands without allowing other users
- to run commands inbetween you can use \fBlock\fP.
- A common example is committing your changes to a module.
- If you don't \fBlock\fP the module first
- there are potential races between the time you update your sources and
- the time you commit them, and between the time you commit them and
- update the installed copy.
- To prevent these races you should \fBlock\fP any modules you want to commit,
- then run any \fBcommit\fP commands, verify that the installed sources
- are correct, then \fBunlock\fP the modules.
- The \fB\-w\fP
- option
- creates a write lock (the default), so that you have exclusive
- access to the module.
- The \fB\-r\fP
- option creates a read lock, allowing other users to read the module
- but not modify it.
- See the \fBunlock\fP command below.
- .TP
- \fBlog\fP [\fB\-l\fP] [\fIrlog_options\fP] [\fIfiles...\fP]
- Same as for \fBcvs\fP. Does an \fBrlog\fP on the specified files, or on
- every file in the current directory.
- \fBLog\fP is recursive unless the \fB\-l\fP option is specified.
- See the \fBcvs\fP man page for details.
- .TP
- \fBpack\fP [\fB\-l\fP] [\fIdirs...\fP]
- The pack command is used to put entries for all symbolic links in the
- given directories (or the current directory) into the file \fISCVS/links\fP
- (see \fBFILES\fP section below).
- This file can then be used later by the \fBunpack\fP command to recreate
- the symbolic links.
- The \fBpack\fP command is run
- implicitly during a \fBcommit\fP,
- and is not usually invoked explicitly.
- \fBPack\fP is recursive, unless
- the \fB\-l\fP option is given.
- .TP
- \fBpatch\fP [\fB\-Qqlf\fP] [\fB\-s\fP|\fB\-t\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP]] \fImodules...\fP
- Same as for \fBcvs\fP.
- Creates a \fBpatch\fP file between the two versions of the modules.
- See the \fBcvs\fP man page for details.
- .TP
- \fBremove\fP \fIfiles...\fP
- Same as for \fBcvs\fP.
- Removes the specified files from the repository.
- The files are not actually deleted until the current module is \fBcommit\fPted.
- See the \fBcvs\fP man page for details.
- .TP
- \fBstatus\fP [\fB\-l\fP] [\fIfiles...\fP]
- Same as for \fBcvs\fP.
- Prints out the \fBrcs\fP version in your copy of the file
- and the current \fBrcs\fP version of the file in the repository.
- \fBStatus\fP is recursive unless the \fB\-l\fP option is specified.
- See the \fBcvs\fP man page for details.
- .TP
- \fBtag\fP [\fB\-Qqlfn\fP] [\fB\-d\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP] \fIsymbolic_tag\fP \fImodules...\fP
- Same as for \fBcvs\fP.
- Assigns a symbolic tag name to the given (or current) version of the
- sources in the repository.
- See the \fBcvs\fP man page for details.
- .TP
- \fBunlock\fP [\fB\-a\fP] [\fImodules...\fP]
- Removes any locks you have on the modules.
- If the \fB\-a\fP option is given then all locks on the module are removed.
- See the \fBlock\fP command above.
- .TP
- \fBunpack\fP [\fB\-l\fP] [\fIdirs...\fP]
- Creates symbolic links in the specified directories (or the current directory)
- from the contents of the SCVS.links file.
- The \fBunpack\fP command is run
- implicitly during a \fBcheckout\fP or \fBupdate\fP,
- and is not usually invoked explicitly.
- \fBUnpack\fP is recursive, unless
- the \fB\-l\fP option is given.
- .TP
- \fBupdate\fP [\fB\-QqlfpB\fP] [\fB\-e \fIdir\fP] [\fB\-d\fP] [\fB\-r\fP \fItag\fP|\fB-D\fP \fIdate\fP] [\fImodules...\fP] [\fIfiles...\fP]
- The update command is used to make your copies of modules up-to-date with
- the sources in the repository.
- The default behavior is to bring your copy up-to-date with the version
- that was checked out, although this can be modified with the \fB\-r\fP
- or \fB\-D\fP options.
- You will have to specify these options to subsequent \fBupdate\fP commands
- if you wish to continue to use a different version than the one that
- was checked out.
- \fBUpdate\fP is recursive by default, but this can be overridden by the
- \fB\-l\fP option.
- The \fB\-B\fP option will cause \fBupdate\fP to not update your sources
- with any new directories in the repository. The default behavior is
- to do so (this differs from \fBcvs\fP).
- See the
- \fBcvs\fP man page for more details on the algorithm used by \fBupdate\fP
- and for an explanation of its output.
- .TP
- \fBwho\fP [\fImodules...\fP]
- Prints out the names of users who have checked out copies of the modules.
- .SH FILES
- .TP
- \fBSCVS.config\fP
- When \fBscvs\fP is invoked it works its way up the directory tree looking for
- the file \fBSCVS.config\fP.
- The first one that is found is used. The \fBSCVS.config\fP
- file has the following
- format. A blank line or a line beginning with '#' is ignored. A line
- beginning with \fBcvsroot:\fP specifies the pathname of the \fBcvs\fP root
- directory.
- '\" A line beginning with \fBobjdir:\fP specifies the pathname of a directory
- '\" tree that contains a copy of the most recent version of the modules,
- '\" along with their object files. The contents of this tree are used to populate
- '\" user's copies of modules with the current object files.
- The following is a sample SCVS.config
- file for the Sprite kernel sources.
- .SP
- .sp
- .in +1i
- .ft C
- .nf
- cvsroot: /sprite/src/kernel/Cvsroot
- installdir: /sprite/src/kernel
- '\" objdir: /sprite/src/kernel
- .fi
- .ft P
- .in -1i
- .sp
- .TP
- \fBSCVS/args\fP
- This file is created by the \fBcheckout\fP command, and is put in the
- top-level subdirectory of a module copy. It contains the arguments
- passed to the \fBcheckout\fP
- command, so that subsequent \fBupdate\fP commands
- use the correct version of the sources.
- .TP
- \fBSCVS/links\fP
- The \fBSCVS/links\fP file contains information about symbolic links in the
- module sources.
- Each line is of the form "\fIlinkName\fP \fItarget\fP",
- where \fIlinkName\fP is the name of the symbolic link to be created, and
- \fItarget\fP is the file to which the link points.
- \fBSCVS/links\fP is created by the \fBpack\fP and \fBcommit\fP commands,
- and read by the \fBcheckout\fP and \fBupdate\fP commands.
- Each subdirectory of a module has its own \fBSCVS/links\fP file.
- .TP
- \fBSCVS/users\fP
- The \fBSCVS/users\fP file exists in each module in the repository and contains
- information about the users who have the module checked out.
- Each line is of the form: "\fIuser\fP \fIpath\fP \fIdate\fP",
- where \fIuser\fP is the name of the user who has the module checked out,
- \fIpath\fP is the pathname of their copy of the module,
- and \fIdate\fP is the time
- when the copy was checked out.
- .TP
- \fBSCVS/locks\fP
- Exists in the module directory in the repository and contains a
- list of locks on the module. Each line is of the form
- "\fItype user date\fP", where \fItype\fP is one of \fIr\fP or \fIw\fP,
- \fIuser\fP is the login name of the lock owner, and
- \fIdate\fP is the time the lock was created.
- .SH SEE ALSO
- \fBrcs\fP(1), \fBci\fP(1), \fBco\fP(1), \fBrcsdiff\fP(1), \fBpatch\fP(1),
- \fBrcsmerge\fP(1), \fBrlog\fP(1), \fBcvs\fP(1)
- .SH KEYWORDS
- source control, rcs, cvs
-
-